Use `setup-codeql` logic for finding release assets in `start-proxy` by mbg · Pull Request #4198 · github/codeql-action

mbg · 2026-10-06T15:24:04Z

The start-proxy Action currently uses its own getReleaseByVersion function to get hold of the release that we expect to find the proxy assets at. That function has hard-coded owner and repo values for the default github/codeql-action repository. This repository may not be available in all environments. In such environments, getReleaseByVersion fails and we fall-back to the hard-coded release obtained from getFallbackUrl instead.

Broadly, this PR does the following:

getCodeQLActionRepository and getCodeQLBundleDownloadURL are refactored out of setup-codeql into a new setup/repository module.
We then use getCodeQLAssetDownloadURL (renamed from getCodeQLBundleDownloadURL) in the start-proxy action to apply the same logic for finding a suitable release as used by setup-codeql.
The hard-coded fallback has been removed. The default URL returned by getCodeQLBundleDownloadURL is essentially equivalent, except that it uses the linked version rather than a hard-coded one. We have been shipping proxy artifacts successfully with releases for a good while now, so the fallback shouldn't be needed anymore.

There are some drive-by improvements to logging and assertions for sinon stubs.

Risk assessment

For internal use only. Please select the risk level of this change:

Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

Managed - Impacts users with dynamic workflows (Default Setup, Code Quality, ...).

Products:

Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
Code Quality - The changes impact analyses when analysis-kinds: code-quality.
Other first-party - The changes impact other first-party analyses.

Environments:

Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

How did/will you validate this change?

Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).
End-to-end tests - I am depending on PR checks (i.e. tests in pr-checks).

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

How will you know if something goes wrong after this change is released?

Telemetry - I rely on existing telemetry or have made changes to the telemetry.
- Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
- Alerts - New or existing monitors will trip if something goes wrong with this change.

Are there any special considerations for merging or releasing this change?

No special considerations - This change can be merged at any time.

Merge / deployment checklist

Confirm this change is backwards compatible with existing workflows.
Consider adding a changelog entry for this change.
Confirm the readme and docs have been updated if necessary.

henrymercer · 2026-10-07T16:24:33Z

+    },
+  );
+
+  for (const [apiURL, repository] of uniqueDownloadSources) {


This is just a URL, not an API URL, i.e. it doesn't start with api.

The name was just copied from setup-codeql.ts, but I have renamed this to instanceURL to address the feedback. While doing that I also noticed that apiURL /instanceURL isn't actually used at all beyond the short-circuit check and in log messages. That seems like it may have been an oversight in your PR when you added this, because without this we just end up checking for the repos on whatever instance getApiClient decides to use instead of the intended apiURL /instanceURL?

without this we just end up checking for the repos on whatever instance getApiClient decides to use instead of the intended apiURL /instanceURL?

Sorry, could you explain what you mean by this? The intent is to check the called Action repo on the same GH instance, the canonical github/codeql-action on the same GH instance, followed by github/codeql-action on Dotcom.

henrymercer · 2026-10-07T16:30:19Z

+  /**
+   * Asserts that `stub` must have been called once with at least the `expected` arguments.
+   */
+  onceWith: <TArgs extends readonly any[]>(


Beyond your later fix in f9a9962, I think this should just be calledWith, since unlike calledOnce / calledOnceWithExactly / calledOnceWithMatch we don't validate that the stub was only called once.

I am unsure if your comment here is a request to change anything, since f9a9962 has addressed this in the way I had intended.

The matchers calledOnce, calledOnceWithExactly, and calledOnceWithMatch in sinon each require exactly one call in total, irrespective of the match, whereas this matcher permits the function to be called multiple times. So for consistency I think we should drop the once from the name of this matcher in favour of something like calledWith or calledAtLeastOnceWith.

henrymercer

Couple of additional comments

henrymercer · 2026-10-07T16:45:24Z

+/** Types that all of our logging functions accept. */
+export type Loggable = string | string[];


Looking back at this after a commit-by-commit review, does anything use this? If not, let's remove it.

It's used by other definitions in logging.ts below (same commit that introduced the definition).

Ah, I mean to say that none of our source code passes an array to a logger. We can keep it if you feel strongly about it though.

I mean to say that none of our source code passes an array to a logger

Ah. I did have at least one place that used this when I added it but maybe that went away while I was working on this PR. In any case, I have come across the same need in some of my other work, so I do think this is a useful addition whether this PR makes use of it or not.

github-actions Bot added the size/L May be hard to review label Oct 6, 2026

mbg force-pushed the mbg/start-proxy/deprecate-fallback branch from 362e7d4 to cd87ccd Compare October 6, 2026 15:56

mbg added 8 commits October 6, 2026 17:07

Allow logging functions to accept string[] directly

909fda1

Refactor getCodeQLActionRepository out of setup-codeql

cb7acf5

Use ActionState for getCodeQLActionRepository

3f57a00

Refactor getCodeQLBundleDownloadURL out of setup-codeql

da07d40

Add utility for assertions on sinon stubs with better output by default

35f12de

Type the assetKind parameter

a4f9f6f

Add getDefaultDotComDownloadURL

de99f0e

Use getCodeQLAssetDownloadURL for start-proxy

133ffeb

mbg force-pushed the mbg/start-proxy/deprecate-fallback branch from cd87ccd to 133ffeb Compare October 6, 2026 16:10

mbg marked this pull request as ready for review October 6, 2026 16:12

mbg requested a review from a team as a code owner October 6, 2026 16:12

mbg requested review from henrymercer and a balanced review from Copilot October 6, 2026 16:12

Copilot started reviewing on behalf of mbg October 6, 2026 16:13 View session

This comment was marked as outdated.

Sign in to view

Fix onceWith not asserting the once part

f9a9962

github-actions Bot added size/XL May be very hard to review and removed size/L May be hard to review labels Oct 6, 2026

henrymercer reviewed Oct 7, 2026

View reviewed changes

mbg mentioned this pull request Oct 7, 2026

Do not use core.exportVariable in unit tests (2nd attempt) #4212

Merged

debanjanbasu mentioned this pull request Oct 10, 2026

start-proxy selects an AMD64 binary on Linux ARM64 #4173

Open

mbg added 6 commits October 12, 2026 14:52

Merge branch 'main' into mbg/start-proxy/deprecate-fallback

265d882

Allow initializeEnvironment to accept Env

c1b620c

Add and use RepositoryNwoStr type

ad8ebce

Use GITHUB_DOTCOM_URL in getDefaultDotComDownloadURL

1a92e13

Use "asset" in comment

e93db40

Use DownloadSource for potentialDownloadSources

fdc069b

mbg added 7 commits October 12, 2026 15:31

DotCom => Dotcom

06bd6e2

Log more in getProxyBinaryPath

3d7016f

Await toolcache.downloadTool

dd3898a

Remove duplicated assertions

ac44fd0

Fix mockGetReleaseByTag usage

a1794a0

Rename apiURL to instanceURL

8fed29e

Add InstanceURL and use in DownloadSource

5aa103d

		/** Types that all of our logging functions accept. */
		export type Loggable = string \| string[];

Conversation

mbg commented Oct 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Risk assessment

Which use cases does this change impact?

How did/will you validate this change?

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

How will you know if something goes wrong after this change is released?

Are there any special considerations for merging or releasing this change?

Merge / deployment checklist

Uh oh!

This comment was marked as outdated.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

henrymercer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mbg commented Oct 6, 2026 •

edited

Loading